Python vs Ruby
Amol Vaidya
debating whether to learn Ruby or Python. How do these compare and contrast
with one another, and what advantages does one language provide over the
other? I would like to consider as many opinions as I can on this matter
before I start studying either language in depth. Any help/comments are
greatly appreciated. Thanks in advance for your help.
Roy Smith
"Amol Vaidya" <myn...@gmail.com> wrote:
Of all the common scripting languages, Ruby has the highest vowel to
consonant ratio.
jean-marc
might not be to another ;-)
Roy Smith
"jean-marc" <jmdes...@cvm.qc.ca> wrote:
> I'd believe that would be Lua, but then again what is common to one
> might not be to another ;-)
Dang, you're right! Lua's got Ruby beat two-fold!
Jason Stitt
And lack of vowels is definitive proof that PHP is not-so-good, right?
How can we improve Python's competitiveness in this arena? "Pie"? Or
can we do even better than Lua? Ptooey!
- Jason
Bryan
why don't you do what i did? download ruby and spend a day or two reading
"programming ruby" from www.ruby-lang.org/en. the download python and spend a
day or two reading the python tuturial from www.python.org. they are very
similar languages and it's going to come down to your personal perference. for
me personally, ruby did not fit in my brain and python did. i used the "how
many times did i have to flip back to a previous page in the manual/tutorial and
reread a section" test. with ruby, once i got about one third of the way
through the manual, i had to constantly reread previous sections. with python,
not once did i need to reread a previous section. therefore, python was the
obvious choice for me.
bryan
jean-marc
But to help a bit more in your balancing act you might take a look at:
http://blog.ianbicking.org/ruby-python-power.html
It's rather nice, and commented.
elbe...@hotmail.com
more.
Dave Cook
> Languages are very similar but Python has more cale avaliable. Much
> more.
Cale? You mean Python has more ruffage?
Dave Cook
Bryan
i think you mean "kale" not "cale". nothing like a hot bowl of tofu kale soup
while reading the recipes in the "python cookbook".
bryan
bruno modulix
> Amol Vaidya wrote:
>
>> Hi. I am interested in learning a new programming language, and have
>> been debating whether to learn Ruby or Python.
>
> why don't you do what i did? download ruby and spend a day or two
> reading "programming ruby" from www.ruby-lang.org/en. the download
> python and spend a day or two reading the python tuturial from
> www.python.org.
Or better: DiveIntoPython
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'on...@xiludom.gro'.split('@')])"
bruno modulix
The main point about "advantages" is that Python has a larger community,
a larger choice of libraries, and is somewhat more mature (which is not
surprising since Python is a little bit older than Ruby).
Else, both are hi-level highly dynamic object oriented languages, both
are fun to program with, and both are easy to get started with. So the
best thing to do is to give both a try and go with the one that fits
your brain.
--
bruno desthuilliers
ruby -e "print 'on...@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
beza1e1
C-syntax-bunch. I'd recommend Python just to learn to adapt a different
syntax. If you want to learn for the learnings sake, i'd also recommend
Haskell to try functional programming, if you do not already know it.
Ruby has some interesting concepts, Python (well CPython) does not
have. Blocks for example, which make Continuations possible. In Python
you need stackless Python (a different implementation) to do this.
gene tani
http://www.ruby-doc.org/RubyEyeForThePythonGuy.html
http://onestepback.org/index.cgi/Tech/Ruby/PythonAndRuby.rdoc
http://www.approximity.com/ruby/Comparison_rb_st_m_java.html
http://www.jvoegele.com/software/langcomp.html
http://reflectivesurface.com/weblog/2004/12/19/why-rails
http://martinfowler.com/bliki/CollectionClosureMethod.html
http://onestepback.org/articles/10things
http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&entry=3284695382
http://www.tbray.org/ongoing/When/200x/2005/08/27/Ruby
http://pleac.sourceforge.net/
http://dev.rubycentral.com/faq/rubyfaq-2.html
Cameron Laird
bruno modulix <on...@xiludom.gro> wrote:
>Bryan wrote:
>> Amol Vaidya wrote:
>>
>>> Hi. I am interested in learning a new programming language, and have
>>> been debating whether to learn Ruby or Python.
>(snip)
>>
>> why don't you do what i did? download ruby and spend a day or two
>> reading "programming ruby" from www.ruby-lang.org/en. the download
>> python and spend a day or two reading the python tuturial from
>> www.python.org.
>
>Or better: DiveIntoPython
.
.
You've already been told all the essentials: that they're similar,
that specific Web pages usefully contrast them, that *Dive into Python*
and so on are worth reading, ... I want to emphasize particularly the
wisdom of trying the two for yourself, to see how each fits your own
tastes. This is practical advice; it truly is possible to have a
meaningful experience with Python and/or Ruby over the course of a day.
These languages are FAR more "light-weight" than, for example, C++,
which typically requires weeks or months of practice before one truly
"gets it". While you won't know everything about, say, Ruby, in the
first four hours, you *will* be able to write programs independently,
and you'll have a "feel" for how the language works as a whole.
Casey Hawthorne
What computer science concepts do you know?
What computer programming concepts do you know?
Have you heard of Scheme?
Ruby is a bit Perl like -- so if you like Perl, chances are you might
like Ruby.
Python is more like Java.
I have heard, but have not been able to verify that if a program is
about
10,000 lines in C++
it is about
5,000 lines in Java
and it is about
3,000 lines in Python (Ruby to?)
Roy Smith <r...@panix.com> wrote:
--
Regards,
Casey
Amol Vaidya
lot of you reccomended and try both for myself, the only problem is finding
time with homework, college applications, and SATs coming up. I'll let you
know how it turns out. Again, thank you all for the help.
Amol Vaidya
"Casey Hawthorne" <caseyhHA...@istar.ca> wrote in message
news:02efl19c4n4994vtl...@4ax.com...
> What languages do you know already?
>
> What computer science concepts do you know?
>
> What computer programming concepts do you know?
>
>
> Have you heard of Scheme?
>
>
> Ruby is a bit Perl like -- so if you like Perl, chances are you might
> like Ruby.
>
> Python is more like Java.
>
> I have heard, but have not been able to verify that if a program is
> about
> 10,000 lines in C++
> it is about
> 5,000 lines in Java
> and it is about
> 3,000 lines in Python (Ruby to?)
I've done a lot of studying on my own, and taken the classes that my
high-school offers. I feel that I have a fairly good understanding of Java,
and basic OO concepts due to that. I've created some semi-complex programs
in java, in my opinion, such as networked checkers, 8-player blackjack, a
space-shooter type game, a copy of mario (one level, anyway), and some other
stuff. I've also done a bit of studying on C. I've done a few projects in C,
including another space-shooter type of game using SDL, an IRC client and
some simple database-type programs. I also gave a shot at assembly using
NASM for x86 before, but didn't get too far. I wrote some trivial code --
wrote to the video buffer, played with some bios interrupts, stuff like
that. The only thing I did in assembly was create a program that loads at
boot-up, and loads another program that just reiterates whatever you type
in. I only did that because I was curious. That's about as far as my
programming knowledge/experience goes.
Well, I'm not sure what you mean by programming concepts. I'm familiar with
OO through Java, and procedural programming through C. I'd be more detailed,
but I'm not exactly sure what you are asking. Sorry.
I have no idea what Scheme is, but I'll cettainly look it up as soon as I'm
done writing this.
I've never given Perl a shot. It was another language I considered learning,
but my father's friend told me to go with Python or Ruby.
Thanks for your help. Hopefully I wasn't too lengthy in this post.
Tom Anderson
> "Casey Hawthorne" <caseyhHA...@istar.ca> wrote in message
> news:02efl19c4n4994vtl...@4ax.com...
>
>> What languages do you know already? What computer science concepts do
>> you know? What computer programming concepts do you know? Have you
>> heard of Scheme?
Good questions!
>> Ruby is a bit Perl like -- so if you like Perl, chances are you might
>> like Ruby.
I don't think rubyists would appreciate that description. Ruby may be
heavier on the funky symbols than python, but it's a very clean, elegant,
usable, well-thought-out and deeply object-oriented language - in other
words, nothing at all like perl.
>> Python is more like Java.
Python is *nothing* like java.
>> I have heard, but have not been able to verify that if a program is
>> about
>> 10,000 lines in C++
>> it is about
>> 5,000 lines in Java
>> and it is about
>> 3,000 lines in Python (Ruby to?)
ITYM 300. Yes, ruby too.
> I've done a lot of studying on my own, and taken the classes that my
> high-school offers. I feel that I have a fairly good understanding of
> Java, and basic OO concepts due to that. I've created some semi-complex
> programs in java, in my opinion, such as networked checkers, 8-player
> blackjack, a space-shooter type game, a copy of mario (one level,
> anyway), and some other stuff. I've also done a bit of studying on C.
> I've done a few projects in C, including another space-shooter type of
> game using SDL, an IRC client and some simple database-type programs. I
> also gave a shot at assembly using NASM for x86 before, but didn't get
> too far. I wrote some trivial code -- wrote to the video buffer, played
> with some bios interrupts, stuff like that. The only thing I did in
> assembly was create a program that loads at boot-up, and loads another
> program that just reiterates whatever you type in. I only did that
> because I was curious. That's about as far as my programming
> knowledge/experience goes.
An excellent start!
> Well, I'm not sure what you mean by programming concepts. I'm familiar
> with OO through Java, and procedural programming through C. I'd be more
> detailed, but I'm not exactly sure what you are asking. Sorry.
I think i know what Casey means, but i don't know if i can explain it any
better. Do you understand the concept orthogonality? The Once And Only
Once principle? Have you ever heard of design patterns?
> I have no idea what Scheme is, but I'll cettainly look it up as soon as
> I'm done writing this.
You won't like it. Give yourself another 5-10 years, and you might start
to find it strangely intriguing.
> I've never given Perl a shot. It was another language I considered
> learning, but my father's friend told me to go with Python or Ruby.
Your father has good friends.
> Thanks for your help. Hopefully I wasn't too lengthy in this post.
Lengthy is fine!
Anyway, the upshot of all this is that, yes, you should learn python.
Python is dope!
tom
--
NOW ALL ASS-KICKING UNTIL THE END
bon...@gmail.com
python or Ruby. Both are fine. But Python has the obvious advantage
that it has much more modules than Ruby so many things you don't need
to implement if you have real work to do.
I recommend you give haskell a shot if you are "in" to programming
because it makes you think differently, not necessary better(at least
not all the time) but helps.
I am not sure your intention but I think there isn't a one language
fits all situation here. I frequently use the following:
C/C++ - for linux kernel hacking etc., many library out there still use
it
python - generic stuff
SQL - nothing beats it for many business apps
haskell - a language to train my brain
javascript - Web front end
other than haskell and SQL, the others are more or less the same to me
so getting familiar with them is not too difficult.
Mike Meyer
> I am not sure your intention but I think there isn't a one language
> fits all situation here.
Very true.
> C/C++ - for linux kernel hacking etc., many library out there still use
> it
> python - generic stuff
> SQL - nothing beats it for many business apps
> haskell - a language to train my brain
> javascript - Web front end
>
> other than haskell and SQL, the others are more or less the same to me
> so getting familiar with them is not too difficult.
There are actually lots of good "train your brain" type
languages. Members of the LISP family, for instance, to learn what you
can do with lists, and also for how cool a real macro facility can
be. I happen to like Scheme, but that's just me. APL, for learning you
can do with arrays. SNOBOL for old-school string processing and
pattern matching. Icon for what you can do with failure. Eiffel for
what you can do with objects and DbC. CLU for duck typing with
declerations. Prolog for what you can do without writing commands. Oz
includes a nice combination of a lot of these things.
The best ones have a book associated with them that teaches general
programming practices using said language as an example - and
hopefully does a good job of it. I've only got four of those:
Scheme: Structure and Interpretation of Computer Programs, by Abelson,
Sussman and Sussman. Commonly called SICP. Available online at <URL:
http://mitpress.mit.edu/sicp/full-text/book/book.html >.
Oz: Concepts, Techniques and Models of Computer Programming, by Van
Roy and Haridi. Sometimes shortened to "The Oz book." Read more about
it at <URL: http://www2.info.ucl.ac.be/people/PVR/book.html >.
Eiffel: Object Oriented Software Construction, by Bertrand
Meyer. Referred to as OOSC. Read more about it at <URL:
http://archive.eiffel.com/doc/oosc/ >.
LISP: On LISP, by Paul Graham. Download it at <URL:
http://www.paulgraham.com/onlisp.html >.
The first three are books about programming that happen to use a
specific language that supports the techniques the authors want to
discuss. On LISP on the other hand is more about what's unique about
LISP programming, at least when compared to more conventional
languages. A lot of what's good about LISP is also good about Python,
so a lot of what he has to say carries over into Python. It's also the
only place to get a thorough look at LISP macro programming, which
knowledge does *not* carry over into Python - but you'll understand
why people ask for macros in Python :-).
If you know of some book/language pair that you think everyone would
benefit from reading, I'd be interested in hearing about them.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Michele Simionato
>> I have no idea what Scheme is, but I'll cettainly look it up as soon as
>> I'm done writing this.
> You won't like it. Give yourself another 5-10 years, and you might start
> to find it strangely intriguing.
+1 ;-)
Michele Simionato
Harald Armin Massa
> I have heard, but have not been able to verify that if a program is
> about
> 10,000 lines in C++
> it is about
> 5,000 lines in Java
> and it is about
> 3,000 lines in Python (Ruby to?)
BTW: it is normally only 50 lines in Perl. Not that you could read it,
though
Harald
Torsten Bronger
At least they could form a heart.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646
Tom Anderson
> "bon...@gmail.com" <bon...@gmail.com> writes:
>
>> other than haskell and SQL, the others are more or less the same to me
>> so getting familiar with them is not too difficult.
>
> There are actually lots of good "train your brain" type languages.
> Members of the LISP family, for instance, to learn what you can do with
> lists, and also for how cool a real macro facility can be. I happen to
> like Scheme, but that's just me.
I haven't actually done anything much in any LISP, but Scheme definitely
looks like a winner to me - single namespace, generally cleaned-up
language and library, etc.
tom
--
For one thing at least is almost certain about the future, namely, that very much of it will be such as we should call incredible. -- Olaf Stapledon
Alex Stapleton
Perl is more like a CISC CPU. There are a million different commands.
Python is more RISC like.
Line count comparisons = pointless.
bruno modulix
> "Casey Hawthorne" <caseyhHA...@istar.ca> wrote in message
> news:02efl19c4n4994vtl...@4ax.com...
>
>>What languages do you know already?
>>
>>What computer science concepts do you know?
>>
>>What computer programming concepts do you know?
>>
>>
>>Have you heard of Scheme?
>>
>>
>>Ruby is a bit Perl like -- so if you like Perl, chances are you might
>>like Ruby.
Ruby is a whole lot Smalltalk-like -- so if you like Smalltalk... !-)
>>Python is more like Java.
<troll>
Err... Python is more like what Java would have been if Java was a smart
dynamic hi-level object oriented language !-)
</troll>
>>I have heard, but have not been able to verify that if a program is
>>about
>>10,000 lines in C++
>>it is about
>>5,000 lines in Java
>>and it is about
>>3,000 lines in Python (Ruby to?)
For a whole lot of common tasks (like file IO etc), the Java/Python loc
ratio is between 5/1 and 10/1. Also, not having the dumbest type system
in the world, Python is naturally much more generic than Java, which
saves a lot of boilerplate code. I think that the real numbers would be
much like 5000 lines in Java -> 1000 lines in Python - and probably 5000
-> 500 in some cases.
>
> I've done a lot of studying on my own, and taken the classes that my
> high-school offers. I feel that I have a fairly good understanding of Java,
> and basic OO concepts due to that.
<IMHO>
Err... I wouldn't start another HolyWar, but Java is not that Object
Oriented. 'Class-based' would be more appropriate. Python, while not
being class-based (ie: it doesn't impose that all code goes into a
'class' statement), is much more an OO language than Java, since in
Python *everything* is an object - even functions, classes and modules.
This makes a *big* difference.
So yes, you may have learned some basic 00 concepts with Java (classes,
instances, inheritence and polymorphism), but with Python and/or Ruby,
you will probably realize that there's much more in the OO paradigm than
all the Java world can dream of.
</IMHO>
>
> Well, I'm not sure what you mean by programming concepts. I'm familiar with
> OO through Java, and procedural programming through C. I'd be more detailed,
> but I'm not exactly sure what you are asking. Sorry.
patterns, metaclasses, aspects, closures, anonymous functions,
higher-order functions, multiple dispatch, properties (computed
attributes), generators, list expressions... does that ring a bell ?
> I have no idea what Scheme is, but I'll cettainly look it up as soon as I'm
> done writing this.
Scheme is a Lisp dialect - Lisp being one of the oldest programming
languages, and one of the most modern programming languages. Whatever
the latest overhyped revolutionary new silver bullet buzzword stuff, you
can bet your ass Lisp already had it many years ago.
Now Lisp never managed to make it to the mainstream... It's a language
(well, a familly of languages should I say) that is worth learning, but
probably not until you've become familiar with some Python features and
idioms.
Another language that failed to make it to the mainstream but is worth
giving a try is Smalltalk - the father of OOPLs (Simula being the
GrandFather). BTW, most of Ruby's feature have been happily stolen from
Smalltalk !-)
> I've never given Perl a shot. It was another language I considered learning,
> but my father's friend told me to go with Python or Ruby.
+1
Michael Ekstrand
> >>Python is more like Java.
>
> <troll>
> Err... Python is more like what Java would have been if Java was a
> smart dynamic hi-level object oriented language !-)
> </troll>
+1. Python is easily applicable to most of the problem domain of Java,
but solves problems much more elegantly. It just isn't shipped embedded
in all leading browsers :-(.
- Michael
Sion Arrowsmith
>> "Casey Hawthorne" <caseyhHA...@istar.ca> wrote in message
>> news:02efl19c4n4994vtl...@4ax.com...
>>>about
>>>10,000 lines in C++
>>>it is about
>>>5,000 lines in Java
>>>and it is about
>>>3,000 lines in Python (Ruby to?)
>
>For a whole lot of common tasks (like file IO etc), the Java/Python loc
>ratio is between 5/1 and 10/1. Also, not having the dumbest type system
>in the world, Python is naturally much more generic than Java, which
>saves a lot of boilerplate code. I think that the real numbers would be
>much like 5000 lines in Java -> 1000 lines in Python - and probably 5000
>-> 500 in some cases.
I have here a library (it's the client side of a client-server
interface including a pile of class definitions) which has
implementations in pure C++, Java and Python, taking about 3000,
3500 and 1500 loc respectively. And there's an associated module
(with no C++ implementation) that I remember being particular
"impressed" while writing it to find being 3 times as long in Java
as Python despite (a) extensive (and pretty much common) Javadoc/
docstrings and (b) implementing in the Python version a feature
present in the standard Java library (scheduling a thread to run
at specified intervals and time out). Strip the Javadoc/docstrings
out and it's about at that 5:1 ratio.
As for Ruby, looking at some of the comparisons given elsewhere
in this thread, my intuition is that it would be more loc than
Python due to all the explicit end s.
--
\S -- si...@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump
vdrab
someone posts a question with nuclear flame war potential like "python
vs. ruby" and after a while people go off singing hymns about the
beauty of Scheme...
I love this place.
v.
Tom Anderson
+1 QOTW
> I love this place.
Someone should really try posting a similar question on c.l.perl and
seeing how they react ...
tom
--
Transform your language.
Scott David Daniels
> ... Another language that failed to make it to the mainstream but is
> worth giving a try is Smalltalk - the father of OOPLs (Simula being the
> GrandFather).
the toofather.
--Scott David Daniels
scott....@acm.org
Ed Jensen
> I have here a library (it's the client side of a client-server
> interface including a pile of class definitions) which has
> implementations in pure C++, Java and Python, taking about 3000,
> 3500 and 1500 loc respectively. And there's an associated module
> (with no C++ implementation) that I remember being particular
> "impressed" while writing it to find being 3 times as long in Java
> as Python despite (a) extensive (and pretty much common) Javadoc/
> docstrings and (b) implementing in the Python version a feature
> present in the standard Java library (scheduling a thread to run
> at specified intervals and time out). Strip the Javadoc/docstrings
> out and it's about at that 5:1 ratio.
This claim seems pretty dubious to me.
Peter Hansen
> Dave Cook wrote:
>> Cale? You mean Python has more ruffage?
>
> kale soup while reading the recipes in the "python cookbook".
Well, if he's going to talk about "ruffage" instead of "roughage",
perhaps he really did mean "cale" and not "kale". ;-)
Kent Johnson
> I have heard, but have not been able to verify that if a program is
> about
> 10,000 lines in C++
> it is about
> 5,000 lines in Java
> and it is about
> 3,000 lines in Python (Ruby to?)
My experience is that Java:Python is roughly 2:1, the highest I have seen (on small bits of code) is 3:1.
Kent
Bryan
i would not say sion's ratio of 5:1 is dubious. for what it's worth, i've
written i pretty complex program in jython over the last year. jython compiles
to java source code and the number of generated java lines to the jython lines
is 4:1.
bryan
Alex Martelli
> Hi. I am interested in learning a new programming language, and have been
> debating whether to learn Ruby or Python. How do these compare and contrast
> with one another, and what advantages does one language provide over the
> other? I would like to consider as many opinions as I can on this matter
> before I start studying either language in depth. Any help/comments are
> greatly appreciated. Thanks in advance for your help.
Within the panorama of existing languages, Python and Ruby are just
about as similar as two languages independently developed are likely to
get (and then some -- there is clearly some minor mutual influence, e.g.
Ruby probably picked 'def' for function definition partly-because that's
what Python uses, and later Python may have picked 'yield' for
generators partly-because that's what Ruby uses to have a method
interact with a block it gets passed). They address the same niches and
share most of the same strengths (and minor weaknesses).
Pragmatically, Python is more mature -- with all sort of consequences,
e.g., Python will be faster for many tasks (more time has been spent on
optimizing it), more third-party libraries and tools are available, etc,
but the Python community may be less easy to "get into" than the newer,
smaller Ruby one, for example.
Here's a tiny script showing some similarities and differences:
def f()
i = 0
while i < 1000000
j = 923567 + i
i += 1
end
end
f()
comment out the 'end' statements, and at colons at the end of the def
and while statements, and this is also valid Python. On my iBook...:
Helen:~ alex$ time ruby -w tim.rb
real 0m5.367s
user 0m5.129s
sys 0m0.041s
while:
Helen:~ alex$ time python tim.py
real 0m1.078s
user 0m0.953s
sys 0m0.063s
Note that this is NOT the normal way to loop in either language, so do
NOT read too much into the reported times -- a 5:1 ratio is NOT normally
observed on real tasks, though it IS reasonably normal for Python to be
somewhat faster. BTW, this is Python 2.4.1 and Ruby 1.8.2.
I'm pretty sure that the Ruby community at some point will go through
much the same exercise the Python one did in the several years spent on
the transitions 2.2 -> 2.3 -> 2.4 -- reduce the amount of change in the
language and library and focus most development effort on optimization
instead. I know of no intrinsic reason why Ruby and Python should not
deliver just about equal performance for similar tasks, though the
current implementations may not be equivalent (yet) from this POV.
Python in recent years moved to enhance its object model (making it in
some ways closer to Ruby) and iteration abilities (ditto), while Ruby
moved to shed more and more of its Perl legacy (though in both cases
legacy issues may have slowed down progress a little bit, yet for both
languages the direction is clear). This makes the two languages more
similar and to some extent interchangeable.
Ruby has acquired a framework ("Ruby on Rails") that makes it very
desirable to implement database-backed web sites; while Python's running
hot after it (e.g. with Django), for this specific task Rails is better
today (e.g., you can get good _books_ about Rails, but not yet about
Django). "Ruby Gems" is a good package management system that is fully
operational today; again, Python's catching up, but it's not there yet.
For other things, Python's existing base of third-party extensions and
tools is above Ruby's. For example, Numeric (and numarray and scipy,
etc) make Python excellent for heavy-duty number crunching, and I do not
know of Ruby equivalents in this area; Twisted is a great framework for
asynchronous network programming, and, again, it's a Python advantage;
and so on, and so forth. However, there is a downside: for some tasks
(e.g., web-site frameworks) Python has _too many_ good 3rd party
extensions available, making it hard to choose among them!
We can proceed to compare the languages themselves. Many differences
are minor and cosmetic. Typically, Python is more specific, giving you
fewer cosmetic choices: e.g., you must use parentheses in defining and
calling functions, while, in Ruby, parentheses are optional (though
often recommended) for these same tasks. Ruby's approach of having
everything be an object on the same plane, infinitely modifiable until
and unless explicitly frozen, is more regular, while Python's approach
of giving slightly special status to built-in types and making them not
modifiable dynamically is slightly less regular but may be more
pragmatic. OTOH, Python's approach to "callable objects" (essentially
making them all fully interchangeable) is the more regular of the two.
Ruby's approach to iteration (passing the code block into a method) is
essentially equivalent to Python's (iterators and generators), with
several minor advantages and disadvantages on either side. One could go
on for quite a long time, but to some extent these are all minor
quibbles, nothing really earth-shaking in the mix. Writing Ruby
extensions in C is slightly easier (thanks to mark-and-sweep garbage
collecton, mostly), but Python offers many alternatives (e.g., pyrex)...
Personally, I'm happy to stick with Python, but I keep studying Ruby
when new books &c about it come out (I'm biased, having written Python
books, but the Ruby books from the "pragmatic programmers" are also
quite good ones, no two ways about it). I think that if you try both
and consider accurately all the uses you may want to put them to, you'll
most probably be happy with either... or both!
Alex
Robert Boyd
>
> How can we improve Python's competitiveness in this arena? "Pie"? Or
> can we do even better than Lua? Ptooey!
I'm sure I could really evangelize use of it at work were it called Ptooey ;)
As if Plone, Zope, and (non-Python) Shibboleth weren't getting me
enough funny looks. And I haven't even started telling co-workers
about Django.
Rob
Roy Smith
> As if Plone, Zope, and (non-Python) Shibboleth weren't getting me
> enough funny looks. And I haven't even started telling co-workers
> about Django.
A couple of years ago, a head-hunter asked me if I knew Plone. I figured
he was just being an idiot and didn't know how to spell PL/1. Silly me :-)
Terry Hancock
Why?
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com
Kent Johnson
> i would not say sion's ratio of 5:1 is dubious. for what it's worth,
> i've written i pretty complex program in jython over the last year.
> jython compiles to java source code and the number of generated java
> lines to the jython lines is 4:1.
Ugh. The code generated by jythonc is *nothing like* the code you would write by hand to do the same thing. This is a meaningless comparison.
Kent
Ed Jensen
> i would not say sion's ratio of 5:1 is dubious. for what it's worth, i've
> written i pretty complex program in jython over the last year. jython compiles
> to java source code and the number of generated java lines to the jython lines
> is 4:1.
Most code generators are known to produce non-optimal code.
Steven D'Aprano
>
> On 21 Oct 2005, at 09:31, Harald Armin Massa wrote:
>
>> Casey,
>>
>>
>>
>>> I have heard, but have not been able to verify that if a program is
>>> about
>>> 10,000 lines in C++
>>> it is about
>>> 5,000 lines in Java
>>> and it is about
>>> 3,000 lines in Python (Ruby to?)
I suspect it is considerably less than that, although it depends on the
specific code being written.
>> BTW: it is normally only 50 lines in Perl. Not that you could read it,
>> though
>>
>> Harald
>>
>>
> Perl is more like a CISC CPU. There are a million different commands.
> Python is more RISC like.
> Line count comparisons = pointless.
Not so.
Every line = more labour for the developer = more cost and time.
Every line = more places for bugs to exist = more cost and time.
I find it sometimes helps to imagine extreme cases. Suppose somebody comes
to you and says "Hi, I want you to develop a web scrapping application to
run on my custom hardware." You look at the project specifications and
realise that the hardware has no OS, no TCP/IP, no file manager, no
compiler. So you have to quote the potential customer on writing all these
layers of software, potentially tens of millions of lines of code.
Even porting an existing OS to the new hardware is not an insignificant
job. Think how much time and money it would take.
On the other extreme, the client comes to you and asks the same thing,
except the hardware is a stock-standard Linux-based PC. Your development
environment already contains an operating system, a file manager,
TCP/IP, compilers, frameworks... and wget. The work you need to do is
potentially as little as writing down the command "man wget" on a slip of
paper and pushing it across the table to your customer.
As programming languages go, C is closer to the first extreme, C++ a
little further away, Java further away still, because Java provides
more capabilities already built-in that the C programmer has to
create from scratch. For many tasks, Python provides even more
capabilities, in a language that demands less syntax scaffolding to make
things happen. Every line of code you don't have to write not only is a
bug that just can't happen, but it also saves time and labour.
--
Steven.
Mike Meyer
> On Fri, 21 Oct 2005 13:03:29 +0100, Alex Stapleton wrote:
>> Perl is more like a CISC CPU. There are a million different commands.
>> Python is more RISC like.
>> Line count comparisons = pointless.
>
> Not so.
>
> Every line = more labour for the developer = more cost and time.
> Every line = more places for bugs to exist = more cost and time.
There were studies done in the 70s that showed that programmers
produced the same number of debugged lines of code a day no matter
what language they used. So a language that lets you build the same
program with fewer lines of code will let you build the program in
less time.
> I find it sometimes helps to imagine extreme cases. Suppose somebody comes
> to you and says "Hi, I want you to develop a web scrapping application to
> run on my custom hardware." You look at the project specifications and
> realise that the hardware has no OS, no TCP/IP, no file manager, no
> compiler. So you have to quote the potential customer on writing all these
> layers of software, potentially tens of millions of lines of code.
> Even porting an existing OS to the new hardware is not an insignificant
> job. Think how much time and money it would take.
Then factor in the profits to be reaped from selling the ported
OS/compilers :-).
Alex Martelli
> > Every line = more labour for the developer = more cost and time.
> > Every line = more places for bugs to exist = more cost and time.
>
> There were studies done in the 70s that showed that programmers
> produced the same number of debugged lines of code a day no matter
> what language they used. So a language that lets you build the same
> program with fewer lines of code will let you build the program in
> less time.
Of course, these results only apply where the "complexity" (e.g., number
of operators, for example) in a single line of code is constant. There
is no complexity advantage to wrapping up code to take fewer LINES, as
such -- e.g., in Python:
for item in sequence: blaap(item)
or
for item in sequence:
blaap(item)
are EXACTLY as easy (or hard) to write, maintain, and document -- it's
totally irrelevant that the number of lines of code has "doubled" in the
second (more standard) layout of the code!-)
This effect is even more pronounced in languages which allow or
encourage more extreme variation in "packing" of code over lines; e.g.,
C, where
for(x=0; x<23; x++) { a=seq[x]; zap(a); blup(a); flep(a); }
and
for(x=0;
x<23;
x++)
{
a=seq[x];
zap(a);
blup(a);
flep(a);
}
are both commonly used styles -- the order of magnitude difference in
lines of code is totally "illusory".
Alex
Mike Meyer
> Mike Meyer <m...@mired.org> wrote:
>> > Every line = more labour for the developer = more cost and time.
>> > Every line = more places for bugs to exist = more cost and time.
>> There were studies done in the 70s that showed that programmers
>> produced the same number of debugged lines of code a day no matter
>> what language they used. So a language that lets you build the same
>> program with fewer lines of code will let you build the program in
>> less time.
> Of course, these results only apply where the "complexity" (e.g., number
> of operators, for example) in a single line of code is constant.
I'm not sure what you're trying to say here. The tests ranged over
things from PL/I to assembler. Are you saying that those two languages
have the same "complexity in a single line"?
> for item in sequence: blaap(item)
>
> or
>
> for item in sequence:
> blaap(item)
>
> are EXACTLY as easy (or hard) to write, maintain, and document -- it's
> totally irrelevant that the number of lines of code has "doubled" in the
> second (more standard) layout of the code!-)
The studies didn't deal with maintenance. They only dealt with
documentation in so far as code was commented.
On the other hand, studies of reading comprehension have shown that
people can read and comprehend faster if the line lengths fall within
certain ranges. While it's a stretch to assume those studies apply to
code, I'd personally be hesitant to assume they don't apply without
some reseach. If they do apply, then your claims about the difficulty
of maintaining and documenting being independent of the textual line
lengths are wrong. And since writing code inevitable involves
debugging it - and the studies specified debugged lines - then the
line length could affect how hard the code is to write as well.
Max M
> There were studies done in the 70s that showed that programmers
> produced the same number of debugged lines of code a day no matter
> what language they used. So a language that lets you build the same
> program with fewer lines of code will let you build the program in
> less time.
In my experience the LOC count is *far* less significant than the levels
of indirections.
Eg. how many levels of abstraction do I have to understand to follow a
traceback, or to understand what a method relly does in a complex system.
--
hilsen/regards Max M, Denmark
http://www.mxm.dk/
IT's Mad Science
Alex Martelli
...
> > Of course, these results only apply where the "complexity" (e.g., number
> > of operators, for example) in a single line of code is constant.
>
> I'm not sure what you're trying to say here. The tests ranged over
> things from PL/I to assembler. Are you saying that those two languages
> have the same "complexity in a single line"?
Not necessarily, since PL/I, for example, is quite capable of usages at
extremes of operator density per line. So, it doesn't even have "the
same complexity as itself", if used in widely different layout styles.
If the studies imply otherwise, then I'm reminded of the fact that both
Galileo and Newton published alleged experimental data which can be
shown to be "too good to be true" (fits the theories too well, according
to chi-square tests etc)...
> > for item in sequence: blaap(item)
> >
> > or
> >
> > for item in sequence:
> > blaap(item)
> >
> > are EXACTLY as easy (or hard) to write, maintain, and document -- it's
> > totally irrelevant that the number of lines of code has "doubled" in the
> > second (more standard) layout of the code!-)
>
> The studies didn't deal with maintenance. They only dealt with
> documentation in so far as code was commented.
>
> On the other hand, studies of reading comprehension have shown that
> people can read and comprehend faster if the line lengths fall within
> certain ranges. While it's a stretch to assume those studies apply to
> code, I'd personally be hesitant to assume they don't apply without
> some reseach. If they do apply, then your claims about the difficulty
> of maintaining and documenting being independent of the textual line
> lengths are wrong. And since writing code inevitable involves
> debugging it - and the studies specified debugged lines - then the
> line length could affect how hard the code is to write as well.
If time to code depends on textual line lengths, then it cannot solely
depend on number of lines at the same time. If, as you say, the studies
"prove" that speed of delivering debugged code depends strictly on the
LOCs in the delivered code, then those studies would also be showing
that the textual length of the lines is irrelevant to that speed (since,
depending on coding styles, in most languages one can trade off
textually longer lines for fewer lines).
OTOH, the following "mental experiment" shows that the purported
deterministic connection of coding time to LOC can't really hold:
say that two programmers, Able and Baker, are given exactly the same
task to accomplish in (say) language C, and end up with exactly the same
correct source code for the resulting function;
Baker, being a honest toiling artisan, codes and debugs his code in
"expansive" style, with lots of line breaks (as lots of programming
shops practice), so, given the final code looks like:
while (foo())
{
bar();
baz();
}
(etc), he's coding 5 lines for each such loop;
Able, being able, codes and debugs extremely crammed code, so the same
final code looks, when Able is working on it, like:
while (foo()) { bar(); baz(); }
so, Able is coding 1 line for each such loop, 5 times less than Baker
(thus, by hypothesis, Able must be done 5 times faster);
when Able's done coding and debugging, he runs a "code beautifier"
utility which runs in negligible time (compared to the time it takes to
code and debug the program) and easily produces the same "expansively"
laid-out code as Baker worked with all the time.
So, Able is 5 times faster than Baker yet delivers identical final code,
based, please note, not on any substantial difference in skill, but
strictly on a trivial trick hinging on a popular and widely used kind of
code-reformatting utility.
Real-life observation suggests that working with extremely crammed code
(to minimize number of lines) and beautifying it at the end is in fact
not a sensible coding strategy and cannot deliver such huge increases in
coding (and debugging) speed. Thus, either those studies or your
reading of them must be fatally flawed in this respect (most likely,
some "putting hands forward" footnote about coding styles and tools in
use was omitted from the summaries, or neglected in the reading).
Such misunderstandings have seriously damaged the practice of
programming (and managements of programming) in the past. For example,
shops evaluating coders' productivity in terms of lines of code have
convinced their coders to distort their style to emit more lines of code
in order to be measured as more productive -- it's generally trivial to
do so, of course, in many cases, e.g.
for i in range(100):
a[i] = i*i
can easily become 100 lines "a[0] = 0" and so on (easily produced by
copy and paste or editor macros, or other similarly trivial means). At
the other extreme, some coders (particularly in languages suitable for
extreme density, such as Perl) delight in producing "one-liner"
(unreadable) ``very clever'' equivalents of straightforward loops that
would take up a few lines if written in the obvious way instead.
The textual measure of lines of code is extremely easy to obtain, and
pretty easy to adjust to account for some obvious first-order effects
(e.g., ignoring comments and whitespace, counting logical lines rather
than physical ones, etc), and that, no doubt, accounts for its undying
popularity -- but it IS really a terrible measurement for "actual
program size and complexity".
Moreover, even if you normalized "program size" by suitable language
specific factors (number of operators, decision points, cyclomatic
complexity, etc), the correlation between program size and time to code
it would still only hold within broadly defined areas, not across the
board. I believe "The mythical man-month" was the first widely read
work to point out how much harder it is to debug programs that use
unrestrained concurrency (in today's terms, think of multithreading
without any of the modern theory and helpers for it), which Brooks
called "system programs", compared to "ordinary" sequential code (which
Brooks called "application programs" -- the terminology is quite dated,
but the deep distinction remains valid). Also: one huge monolithic
program using global variables for everything is going to have
complexity (and time to delivery of debugged code) that grows way more
than linearly with program size; to keep a relation that's close to
linear (though in no case can exact linearity be repeatably achieved for
sufficiently large programming systems, I fear), we employ a huge
variety of techniques to make our software systems more modular.
It IS important to realize that higher level languages, by making
programs of equivalent functionality (and with comparable intrinsic
difficulty, modularity, etc) "textually smaller" (and thereby
"conceptually" smaller), raises program productivity. But using "lines
of code", without all the appropriate qualifications, for these
measurements, is not appropriate. Even the definition of a language's
level in terms of LOCs per function point is too "rough and ready" and
thus suffers from this issue (function points as a language-independent
measure of a coding task's "size" have their own issues, but much
smaller ones than LOCs as a measure of a delivered code's size).
Consider the analogy of measuring a writing task (in, say, English) by
number of delivered words -- a very popular measure, too. No doubt, all
other things being equal, it may take a writer about twice as much to
deliver 2000 copy-edited words than to deliver 1000. But... all other
things are rarely equal. To me, for example, it often comes most
natural to take about 500 words to explain and illustrate one concept;
but when I need to be concise, I will then take a lot of time to edit
and re-edit that text until just about all of the same issues are put
across in 200 words or less. It may take me twice as long to rewrite
the original 500 words into 200, as it took to put down the 500 words in
the first place -- which helps explains why many of my posts are so
long, as I don't take all the time to re-edit them, and why it taks so
long to write a "Nutshell" series book, where conciseness is crucial.
Nor it is only my own issue... remember Pascal's "Lettres Provinciales",
and the famous apology about "I am sorry that this letter is so long,
but I did not have the time to write a shorter one"!-)
Alex
bruno modulix
It's been a long time since I last saw a Java applet on a website.
--
bruno desthuilliers
bruno modulix
> bruno modulix wrote:
>
>> ... Another language that failed to make it to the mainstream but is
>> worth giving a try is Smalltalk - the father of OOPLs (Simula being the
>> GrandFather).
>
> I would say Simula is the forefather of modern OOPLs, and Smalltalk is
> the toofather.
Err... I'm afraid I don't understand this last word (and google have not
been of much help here)
--
bruno desthuilliers
bruno modulix
(snip)
> Here's a tiny script showing some similarities and differences:
>
> def f()
> i = 0
> while i < 1000000
> j = 923567 + i
> i += 1
> end
> end
>
> f()
>
> comment out the 'end' statements, and at colons
s/at/add/
> at the end of the def
> and while statements, and this is also valid Python.
--
Iain King
SSshhhhhhhhh! Xah Lee might be listening!
Iain
Scott David Daniels
> Scott David Daniels wrote:
>>bruno modulix wrote:
>>>... Another language that failed to make it to the mainstream but is
>>>worth giving a try is Smalltalk - the father of OOPLs (Simula being the
>>>GrandFather).
>>I would say Simula is the forefather of modern OOPLs, and Smalltalk is
>>the toofather.
> Err... I'm afraid I don't understand this last word (and google have not
> been of much help here)
Sorry, I was being too cute by half. If Simula is the fore father
(4 away) then Smalltalk is half as far (2) away. Hence the "toofather."
"Toofather" by analogy with the homophones "fore" and "four" we use the
homophones "two" and "too".
--Scott David Daniels
scott....@acm.org
Michele Simionato
> ... remember Pascal's "Lettres Provinciales",
> and the famous apology about "I am sorry that this letter is so long,
> but I did not have the time to write a shorter one"!-)
This observation applies to code too. I usually spend most of my time
in making short programs
that would have been long. This means:
cutting off non-essential features (and you can discover that a feature
is non essential only after having implemented it)
and/or
rethinking the problem to a superior level of abstraction (only
possible after you have implented
the lower level of abstraction).
Michele Simionato
Neil Hodgson
> Sorry, I was being too cute by half. If Simula is the fore father
> (4 away) then Smalltalk is half as far (2) away. Hence the "toofather."
> "Toofather" by analogy with the homophones "fore" and "four" we use the
> homophones "two" and "too".
We could smear the homophones further and say OCaml is the "nextfather".
Neil
Alex Martelli
> Alex Martelli wrote:
> > ... remember Pascal's "Lettres Provinciales",
> > and the famous apology about "I am sorry that this letter is so long,
> > but I did not have the time to write a shorter one"!-)
>
> This observation applies to code too. I usually spend most of my time
> in making short programs
> that would have been long. This means:
Absolutely true.
> cutting off non-essential features (and you can discover that a feature
> is non essential only after having implemented it)
This one is difficult if you have RELEASED the program with the feature
you now want to remove, sigh. You end up with lots of "deprecated"s...
somebody at Euro OSCON was saying that this was why they had dropped
Java, many years ago -- each time they upgraded their Java SDK they
found out that half their code used now-deprecated features.
Still, I agree that (once in a while) accepting backwards
incompatibility by removing features IS a good thing (and I look
forwards a lot to Python 3.0!-). But -- the "dream" solution would be
to work closely with customers from the start, XP-style, so features go
into the code in descending order of urgence and importance and it's
hardly ever necessary to remove them.
> and/or
>
> rethinking the problem to a superior level of abstraction (only
> possible after you have implented
> the lower level of abstraction).
Yep, this one is truly crucial.
But if I had do nominate ONE use case for "making code smaller" it would
be: "Once, And Only Once" (aka "Don't Repeat Yourself"). Scan your code
ceaselessly mercilessly looking for duplications and refactor just as
mercilessly when you find them, "abstracting the up" into functions,
base classes, etc...
Alex
Jorge Godoy
> forwards a lot to Python 3.0!-). But -- the "dream" solution would be
> to work closely with customers from the start, XP-style, so features go
> into the code in descending order of urgence and importance and it's
> hardly ever necessary to remove them.
We do that often with two of our customers here. After the first changes,
they asked for more. And them some other and when it finally ended, the
project was like we had suggested, but instead of doing this directly, the
client wanted to waste more money... :-( Even if we earnt more money, I'd
rather have the first proposal accepted instead of wasting time working on
what they called "essential features".
> But if I had do nominate ONE use case for "making code smaller" it would
> be: "Once, And Only Once" (aka "Don't Repeat Yourself"). Scan your code
> ceaselessly mercilessly looking for duplications and refactor just as
> mercilessly when you find them, "abstracting the up" into functions,
> base classes, etc...
And I'd second that. Code can be drastically reduced this way and even
better: it can be made more generic, more useful and robustness is improved.
--
Jorge Godoy <go...@ieee.org>
Michele Simionato
> Michele Simionato:
>> cutting off non-essential features (and you can discover that a feature
>> is non essential only after having implemented it)
> This one is difficult if you have RELEASED the program with the feature
> you now want to remove, sigh.
Yeah, but I used the wrong word "features", which typically means "end
user features".
Instead, I had in mind "developer features", i.e. core features that
will be called later
in "client" code (I am in a framework mindset here).
Typically I start with a small class, then the class becomes larger as
I add features that will
be useful for client code, then I discover than the class has become
difficult to mantain.
So I cut the features and and I implement them outside the class and
the class becomes
short again.
However, I *cannot* know from the beginning what is the minimal set of
features
needed to make short the client code until I write a lot of client
code. I can make things short
only after I have made things long. I think this applies to me, to you,
to Pascal and to
everybody in general. It is impossible to start from the beginning with
the short program,
unless you already know the solution (that means, you have already
written the long
version in the past). Still, some naive people think there is a silver
bullet or an easy way
to avoid the hard work. They are naive ;)
Michele Simionato
Alex Martelli
> ale...@yahoo.com (Alex Martelli) writes:
>
> > forwards a lot to Python 3.0!-). But -- the "dream" solution would be
> > to work closely with customers from the start, XP-style, so features go
> > into the code in descending order of urgence and importance and it's
> > hardly ever necessary to remove them.
>
> We do that often with two of our customers here. After the first changes,
> they asked for more. And them some other and when it finally ended, the
> project was like we had suggested, but instead of doing this directly, the
> client wanted to waste more money... :-( Even if we earnt more money, I'd
> rather have the first proposal accepted instead of wasting time working on
> what they called "essential features".
The customer is part of the team; if any player in the team is not
performing well, the whole team's performance will suffer -- that's
hardly surprising. You may want to focus more on _teaching_ the
customer to best play his part in the feature-selection game, in the
future... not easy, but important.
> > But if I had do nominate ONE use case for "making code smaller" it would
> > be: "Once, And Only Once" (aka "Don't Repeat Yourself"). Scan your code
> > ceaselessly mercilessly looking for duplications and refactor just as
> > mercilessly when you find them, "abstracting the up" into functions,
> > base classes, etc...
>
> And I'd second that. Code can be drastically reduced this way and even
> better: it can be made more generic, more useful and robustness is improved.
I'll second all of your observations on this!-)
Alex
bruno modulix
> bruno modulix wrote:
>
>> Scott David Daniels wrote:
>>
>>> bruno modulix wrote:
>>>
>>>> ... Another language that failed to make it to the mainstream but is
>>>> worth giving a try is Smalltalk - the father of OOPLs (Simula being the
>>>> GrandFather).
>>>
>>> I would say Simula is the forefather of modern OOPLs, and Smalltalk is
>>> the toofather.
>>
>> Err... I'm afraid I don't understand this last word (and google have not
>> been of much help here)
>
>
> Sorry, I was being too cute by half.
tss...
> If Simula is the fore father
> (4 away) then Smalltalk is half as far (2) away. Hence the "toofather."
> "Toofather" by analogy with the homophones "fore" and "four" we use the
> homophones "two" and "too".
My my my...
--
bruno desthuilliers
ruby -e "print 'on...@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
Andy Leszczynski
>
> Every line = more labour for the developer = more cost and time.
> Every line = more places for bugs to exist = more cost and time.
>
The place I work at the creation rate is not a problem - we could crank
out in the team 1000s lines a week. Most time we spend is on maintanance
. This is where Pyton shines over Java/C++/Perl. It is easy to read thus
maintane.
A.
Andy Leszczynski
> Hi. I am interested in learning a new programming language, and have been
> debating whether to learn Ruby or Python. How do these compare and contrast
> with one another, and what advantages does one language provide over the
> other? I would like to consider as many opinions as I can on this matter
> before I start studying either language in depth. Any help/comments are
> greatly appreciated. Thanks in advance for your help.
How Ruby solves the problem of global interpreter lock?
A.
Steven D'Aprano
> Steven D'Aprano wrote:
>
>>
>> Every line = more labour for the developer = more cost and time.
>> Every line = more places for bugs to exist = more cost and time.
>>
>
> The place I work at the creation rate is not a problem - we could crank
> out in the team 1000s lines a week.
Good on you. I assume those thousands of lines are good ones, and not
just churning out quantity instead of quality.
In any case, no matter how fast you are, you will be faster if you have
fewer lines to write.
> Most time we spend is on maintanance
> . This is where Pyton shines over Java/C++/Perl. It is easy to read thus
> maintane.
Yes. Now imagine how much less maintenance you'd have to do with fewer
lines.
Of course, it is easy to take this to extremes. One thing which is a red
rag to me is when folks have written perfectly good, efficient, fast,
readable code in four lines, and then obsess "how can I write this as a
one-liner?". That way to the Dark Side goes: unreadable, cryptic,
unmaintainable, buggy code.
In any case, lines of code is a very poor metric for measuring programmer
productivity. I'm not even so sure it is better than nothing -- in some
cases, it is *worse* than nothing.
--
Steven.
Lawrence Oluyede
> How Ruby solves the problem of global interpreter lock?
AFAIK Ruby does not have those kind of problems, it does not have "real" threads
but it emulates them via software
--
Lawrence
http://www.oluyede.org/blog
bellarc...@gmail.com
bruno modulix wrote:
>
> It's been a long time since I last saw a Java applet on a website.
>
That can only mean you are ignorant.
Applets are a huge deal for Intranets. And Java Web Start is even more
useful. I really wish Python had such wonderful means of deployment.
bruno modulix wrote
> Err... I wouldn't start another HolyWar, but Java is not that Object
> Oriented. 'Class-based' would be more appropriate. Python, while not
> being class-based (ie: it doesn't impose that all code goes into a
> 'class' statement), is much more an OO language than Java, since in
> Python *everything* is an object - even functions, classes and modules.
> This makes a *big* difference.
I think you are confusing terms. Class-based means that the language
uses classes and class inheritance and not object prototyping (as in
javascript):
http://en.wikipedia.org/wiki/Object_oriented#Prototype-based_models
And why should functions be objects ? Actually, this makes it less OOP
if we consider Smaltalk as being true OOP ;)
Python is here more pragmatic but less OOP, please try to remember it.
And haven't you heard of java.lang.Class or java.lang.reflect.Method ?
Classes in Java *ARE* objects. Or do you think all those static methods
and properties just pop out of the ground ? Voodoo maybe ? :)
The reason classes don't behave as objects is because that's only
usefull for reflection and meta-programming and that can be achieved by
using the java.lang.reflect package which IMHO it really makes sense
the way it was implemented.
bruno modulix wrote
> Err... Python is more like what Java would have been if Java was a smart
> dynamic hi-level object oriented language !-)
You see, I rarely see this kind of rubish on comp.lang.ruby. Shame on
you.
Do you realy think you are doing the Python community a favor by
bashing Java ?
<troll>
And yeah, LOC count is stupid. Productivity in general measured in LOC
is stupid. For that Java has a simple syntax which anyone can learn in
only a few hours (simpler than Python's ... a lot imho) and tools like
Eclipse, Netbeans, Studio Creator, JBuilder, etc ...
</troll>